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Metric 


Description 


allocated-memory 


The amount of memory in bytes that a program has dynamically 
allocated. 


allocated-objects 


The count of memory objects that a program has dynamically allocated. 


cpu-utilization 


The fraction of the total time spent actually computing or processing 
data, as opposed to waiting for users, other programs, etc. 


current-threads 


The number of threads that currently exist within a program. 


file-handle-count 


The number of opened files within a program. 


heap-size 


Heap size includes live memory plus any and all overhead associated 
with the performance management system's management of the heap 
(data structures, fragmentation, and other internal use of memory). 


live-memory 


The amount of memory, in bytes, that has been dynamically allocated 
and has not been freed. It includes both reachable memory and leaked 
memory that has not been collected. 


live-objects 


The count of objects that have been dynamically allocated and have not 
been freed. It includes both reachable objects and leaked objects that 
have not been collected. 


number-of-heaps 


The count of how many heaps are in use by a process. 


physical-memory 


Real or actual memory (e.g., RAM), in bytes, that the operating system 
has allocated to this application. 


reachable-memory 


Memory, in bytes, that the program can actually access legitimately 
through program variables. Thus it does not include leaked memory. 


system-time 


The amount of time, in seconds, that a program has spent in the 
"system", as opposed to application code. 


threads-created 


The total number of threads created in a program. This includes both 
threads that currently exist and threads that have been destroyed. 


total-virtual-memory 


The maximum amount of committed virtual memory that can be in use 
on a computer, in bytes. 


user-cpu-utilization 


"CPU utilization", given in seconds, is typically separated into multiple 
components. The "user" portion is the amount of time spent in the 
program code itself, as a fraction of the total time, as opposed to the 
operating system. 


user-time 


The amount of time, in seconds, that a program has spent in application 
code, as opposed to the operating system. 


virtual-memory 


Memory, in bytes, that the operating system has allocated to a program. 
This memory may be "physical" (backed by RAM), or swapped out 
(backed by disk), or unallocated (not backed by anything), if it has not 
been referenced. 


wall-time 


The amount of actual time, in seconds, that a program has been alive. 
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Metric 


Description 


collected-objects 


The count of leaked objects that have been automatically freed by the 
Runtime Agent. 


collected-memory 


The amount of leaked memory, in bytes, that has been automatically freed by 
the Runtime agent. Note: This metric is reported in the console as Recovered 
Memory. 


corrected- 
overwrites 


The count of memory overwrites that have been corrected by the Runtime 
Agent. 


corrected-write- 
after-free 


The count of memory write-after-frees that have been corrected by the 
Runtime Agent. 


exception-count 


The number of exceptions that the program has raised. 


heap-lock- 
contentions 


Heap lock contentions occur when an acquisition attempt is made, but some 
other thread of the process is in the middle of making a heap request, and so 
this thread must wait. A large number of heap lock contentions (i.e., a high 
rate) indicates that dynamic memory allocation is a performance or scalability 
problem. 


leaked-memory 


Memory, in bytes, that has been allocated by a program, not explicitly freed, 
but which is no longer referenced. Leaked memory is thus wasted, since it 
still contributes to program memory requirements, but cannot be used. 


leaked-objects 


The count of objects that have been allocated by a program, not explicitly 
freed, but which are no longer referenced. 


multiple-frees 


A multiple-free occurs when a program explicitly frees the same object more 
than once. This can lead to corruption of the memory allocation system, and 
hence of program memory areas. "Multiple-frees" is the number of such 
instances. 


total-lock- 
contentions 


A program "lock" is a synchronization resource used to mediate access from 
multiple threads or CPUs. If one thread has locked a resource, and another 
thread attempts to access it, the second thread is said to "contend" for the 
lock. A large number of lock contentions (i.e., a high rate) may hurt 
performance or scalability. "Total-lock-contentions" is the count of 
contentions from all types of locks. 


uncorrected- 
overwrites 


A memory overwrite occurs when a program stores a value beyond the actual 
bounds of a memory object. Typically these are uncorrected and could corrupt 
other program memory. "Uncorrected-overwrites" is the number of such 
instances. 


uncorrected-write- 
after-free 


A memory write-after-free occurs when a program explicitly frees a 
dynamically-allocated object, then continues to store into it. Typically these 

j 1 1 11 j it IIT T ■ J 

are uncorrected, and could corrupt other program memory. Uncorrected- 
write-after-free" is the number of such instances. 


wild-frees 


A wild free occurs when a program explicitly frees some memory location 
that was not dynamically allocated in the first place. This can lead to 
corruption of the memory allocation system, and hence of program memory 
areas. "Wild-frees" is the number of such instances. 



Figure 3B 



Metric 


Description 


cpu-count 


The number of CPUs in a computer. 


file-handle-count-limit 


The maximum number of open files within a program. 


physical-memory-limit 


The maximum amount of RAM, in bytes, that the operating 
system will allocate to a particular process. 


physical-memory-size 


The total amount of RAM, in bytes, on a particular computer. 


used-virtual-memory 


The total virtual memory committed for use across all 
programs on a computer, in bytes. 


virtual-memory-limit 


The maximum amount of virtual memory, in bytes, that a 
program could allocate. 
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Metric 


Description 


collections 


The count of how many collections have been run by the Runtime Agent. 
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Metric 


Description 


-rate 


Change over each interval (per minute). Typically rates are presented across 
the last FocalPoint polling interval. 


-trend 


Linear regression over process lifetime (per minute) 


-max 


Maximum over lifetime 


-avg 


Average over lifetime 
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Agents are inserted into one or more applications in a 
distributed management framework 
402 
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Function calls to standard programming functions are 
intercepted by the agents 
404 
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r 


Function calls are routed to alternative implementations 
of the standard programming functions 
406 




f 



Alternative implementations of the standard 
programming functions are used to collect availability 
metrics for the one or more applications 
408 
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Instrumentation options 


-V 


Print out version information and exit. 


-h 


Print out help message and exit. 


-metrics 


Instrument for metrics only (default). If neither -metrics or -forensics is 
specified, it will be instrumented for metrics only. 


-forensics 


Instrument for forensics only. 
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Other options 


-full 


Instrument for all features; i.e., both metrics and forensics 


-q 


Suppress most instrumentation progress output. 


-qi 


Suppress already-instrumented output. 


-s 


Strip line number tables and local variable tables from output. 


-no-manifest-update 


Do not alter archive manifests of instrumented archives. 


-d <out-dir> 


Place instrumented classes/jars and .tjl files into a directory 
tree starting at <out-dir>. Defaults to the current working 
directory. 


-label <label> 


Associates class file with a given string label. 


-log <log-file> 


Log instrumentation progress in <log-file>. 


-p <policy.opt> 


Instrument classes and jar files according to the policies 
found in the <policy.opt> file. 


-j <map-file.jar> 


Places map files in <map-file.jar>. 


-sourcepath <source-path> 


Stores given path to Java source files in mapfiles. 


-batch <batch-file> 


Specifies a file containing a batch of files to instrument, one 
filename per line. 


-bs <backup-suffix> 


Specifies a suffix for backing up original class files (default is 
".bak"). 


-ts <MMddyyyyHH:mm:ss> 


Instrument only those classes modified after the specified 
time. 


-tf <MM dd DD yy yyyy HH 
hhmm ss> 


Pass an alternate time format to use with '-ts 1 , suitable for the 
Java SimpleDateFormat class. 


-r <dir> 


Instrument all class and jar files in and below <dir>. 
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Program code of monitored application is modified to 
include additional instructions 
602 



Additional instructions are used to monitor execution of 
the monitored application in a production environment 

604 



Output (e.g., execution history) is automatically 
generated in response to a triggering event in the 
execution of the monitored application 
606 
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Manager threads are started inside applications 
702 



Manager threads are used to monitor execution of the 
applications in a production environment 
704 
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